This has a slight bug where the mouse cursor will not be centred properly when opening the inventory screen. (i.e. the cursor will appear at weird positions)

As this is a platform limitation (Wayland doesn't support setting the cursor pos), i am not aware of a workaround or fix for this currently, even though it is a very minor bug

(Wayland doesn't support setting the cursor pos)

Yes but you can hack around it in glfw by using zwp_locked_pointer_v1::set_cursor_position_hint 0005-Ability-to-setting-the-cursor-position.patch

And i have tested that on GNOME and KDE, although it's a bit weird on Weston since it does warp the pointer but not on the specific position.

You can test that with my fork

Thank you for letting me know and sharing your fork
i am a beginner with Wayland and Linux in general, so i did not realise this workaround even existed

The issue is that zwp_locked_pointer_v1::set_cursor_position_hint is not accessible in java directly, and GLFW currently does not load function pointers from the Wayland libs (presumably wayland-client.so)

I have not tested this, but in theory it should be possible to load the library functions directly, so workarounds such as zwp_locked_pointer_v1::set_cursor_position_hint can be used with JNI directly in this way

The other issue is this doesn't support tearing-control-unstable-v1 protocol (i can't use the RADV driver + nvidia driver does not support it, and i am inexperienced and don't know how to enable it correctly)

So tearing display modes, such as Immediate Mode and Relaxed FIFO will not be usable in this PR's current state.

Finally this also has glitches with the RADV driver if Queued Frames (i.e. Used SwapChain images) is greater than 2.
However I could use any number of SwapChain images on the Nvidia driver with Wayland without issue.
So its either a RADV driver bug, or more likely i made a mistake with the swapchain handling and/or rest of the code.

Edit: This may in fact have been a GLFW bug after all, as newer versions seem to have reduced artifacts with SwapChain images > 2

Though all testing it appears that RADV has visual flickering bug with between actual and previous frame, when RenderFrameQueue/UsedSwapChainImages higer than 2.

Flickers become less visible in gameplay higher the framerate. Flickers also more intense on RFQ 3 and 5, so optimal setting is 2 (no flickers, but limits FPS to monitor refresh rate) or 4 (unlocks FPS but flickers).

As i tested 240 and more frames per second is the point where flickers is not visible at all. And 120 and lower FPS is the point where gameplay is uncomfortable.

However, through my testing with newer versions of GLFW flickers become less and less more visible with each newer GLFW version even with FPS lower than 120.

I hope that it is just GLFW bug, which will be fixed over time.

lemme try this with my setup 🤠

runs like wonders !

But we still have a crash of the JVM when closing the game. It changes nothing technically but it should be good to check.
Here are my logs.

Peace ❤️

Apparently there is a strange crashing issue which throws exit code 6 when exiting/closing the client. This is apparently due to a segfault that happens when attempting to free the swapchain handle.

This PR also adds the ability to check which GPU vendor + platform is being used during runtime.

So worst case i can add a wayland Specific check to not free the swapchain on Wayland, which should fix the issue, but this workaround isn't ideal due to being a Validation Violation (i.e. not freeing/cleaning up all resources),

So i will only use it as a last resort, especially if this is a common issue.

@thr3343 good luck for porting this to the 1.20.x branch! 🤭